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Description 

BACKGROUND OF THE INVENTION 

1 . FIELD OF THE INVENTION 

[0001] The present invention relates generally to in- 
formation systems, and in particular to a system and 
methods that enable the coordination of activity among 
distributed information systems. 

2. Description of the Related Art 

[0002] The recent change in the structure of business 
organizations, from the independent monolithic entity to 
multiple interdependent businesses, mirrors a similar 
evolution in computer systems from the single main- 
frame to distributed networks of personal computers 
and workstations. Since computer networks are ex- 
tremely efficient in communicating information and per- 
forming activities between distributed sites, modern net- 
works should be the obvious beneficiaries of this revo- 
lution in technology. For example, such routine activities 
as ordering and confirming purchases could be per- 
formed automatically between existing systems by a 
shared computer network. Numerous shortcomings in 
the state of the art, however, prevent full exploitation of 
conventional network technology for inter-enterprise 
purposes. 

[0003] The most pressing problems presented by the 
use of shared networks between business partners are 

(1) the heterogeneity of the partner computer systems, 

(2) the heterogeneity of the data used by the partnersys- 
tems, (3) communication security and reliability be- 
tween systems, and (4) the legal, organizational and cul- 
tural boundaries among partners. 

[0004] With respect to system heterogeneity, organi- 
zations often use combinations of operating systems, 
middleware systems, and software applications that are 
incompatible with one another. Widespread middleware 
deployment is now underway, but interoperation among 
the leading camps has yet to be fully defined. Especially 
problematic are differences at the application level, 
which are fundamental and will continue to challenge 
implementers for some time. 

[0005] With respect to the second problem, data het- 
erogeneity, different applications and users of those ap- 
plications often represent information in different ways 
or use different kinds of information to accomplish the 
same task. These gaps can be particularly significant 
when the applications and their users are distributed 
among different enterprises. Bridging the associated 
syntactic and semantic gaps in information can require 
a mixture of transformation capabilities as well as neu- 
tral objects. 

[0006] With respect to the third problem, communica- 
tion security and reliability, any interaction among the 
systems of a business network requires the presence of 



reliable and secure communication pathways between 
the participants. The concern for security is especially 
prominent when the Internet is used as a link in the com- 
munication pathway, since this medium is susceptible 

5 to eavesdropping and other forms of security attacks. 
[0007] With respect to the fourth problem, any attempt 
to automate business processes between multiple part- 
ners must overcome the numerous non-technical barri- 
ers associated with management of a project distributed 

10 among multiple organizations. These challenges in- 
clude mismatches between project priority and resource 
allocation, language barriers, time zone differences and 
both corporate and governmental regulations. These 
challenges limit the levels of coordination that are 

15 achievable. Any technical solution, therefore, must fo- 
cus on minimizing the scope and complexity of the mu- 
tual commitments required to implement the solution. 
[0008] Currently, there are at least five known meth- 
ods for extending interdependent processes beyond 

20 one computer system to other systems connected by 
conventional computer networking resources. The first 
is the manual approach in which users of multiple com- 
puter systems communicate information between one 
another via telephone, fax, or other media. The commu- 

25 nicated information is then entered by hand into the re- 
spective computer systems. The manual approach may 
be used to bridge gaps in automation, but is obviously 
limited in its ability to tightly couple processes among 
partners in both reliable and efficient manner. 

30 [0009] The second approach, which arose in the era 
of home-grown mainframe applications, is known as 
Electronic Data Interchange (EDI). EDI is a broadly de- 
fined term, but most often refers to a particular set of 
standards, technologies (Value-Added Networks, Direct 

35 Dial-ups, mapping software), and practices used for 
electronic data exchange among companies. In EDI, a 
collection of business information (e.g., a purchase or- 
der) may be exported from one application system, 
mapped into a neutral format, transmitted to a partner 

^0 via a VAN (Value-Added Network), mapped by the part- 
ner into a format suitable for its application, and import- 
ed into the partner application. Alternatively, direct dial- 
ing may be substituted for the VAN, EDI, however, is 
generally batch oriented, requires extensive format cus- 

^5 tomization and does not support processes. 

[0010] The third approach, used when business re- 
quirements do not fit the EDI model, is to use a custom 
system designed and implemented to the users' speci- 
fications. This approach is costly, requires a mixture of 

50 network programming and system integration tasks, 
and serves a specific purpose for specific users only. 
Furthermore, it is inflexible and difficult to modify. 
[0011] Recently, two trends in technology have radi- 
cally changed the ways in which application systems 

55 may be intertwined. As a result, a fourth and fifth ap- 
proach, as well as an adaptation of EDI, must be added 
to the three discussed above. The first trend is the rapid 
expansion of network infrastructure. The most visible 
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component of this infrastructure is the ubiquitous con- 
nectivity provided by the Internet. Nearly all organiza- 
tions are, or soon will be, connected to the Internet. Cou- 
pled with this connectivity is an expanding set of mid- 
dleware technologies and services such as distributed 
object frameworks and message oriented middleware 
that facilitate more tractable distributed applications and 
promise far greater interoperability of software compo- 
nents. 

[001 2] The second trend involves advances in the en- 
terprise application systems that are used by compa- 
nies. Key advances in these systems include develop- 
ment of object interfaces and the development of work- 
flow/process modeling capabilities. Object interfaces 
provide a more flexible and less taxing method of mov- 
ing information to and from applications than prior meth- 
ods such as SQL (Structured Query Language) or file- 
based interfaces. Several application vendors now pro- 
vide the ability to design and implement workflow among 
different application modules. This capability allows 
companies to more easily focus on their business proc- 
esses and makes more obvious the need to connect the 
processes of business partners. 
[0013] The most visible impact of these trends, and 
the fourth approach to extending business interdepend- 
ence is the use of the World Wide Web for business-to- 
business interactions. In this model, an employee in one 
business accesses information, such as catalog or ship- 
ping information, pertaining to the business applications 
of another company by using a standard Web browser. 
This approach, however, is ill-suited to many extended 
enterprise processes that require dependent interac- 
tions among the application systems of different organ- 
izations. 

[0014] The fifth approach exploits recent middleware 
technology which makes possible the creation of high- 
performance distributed applications that are logically 
integrated. Though the same technology may be used 
to provide interoperation among application suites from 
different vendors and among systems at different busi- 
nesses, significant challenges limit feasibility. Foremost, 
employing middleware technology is a programming 
task that require&significant programming skill and spe- 
cial understanding of security, synchronization, and oth- 
er network issues. The cost of such an endeavor may 
be justified for the vendor of a distributed application, 
but companies wishing to engage in a specific extended 
enterprise process are unlikely to devote the capital re- 
quired to build distributed systems from the ground up. 
[0015] Finally, the adaptation of EDI, referred to as In- 
ternet-EDI, is actually a number of methods that attempt 
to move the traditional EDI approach discussed above 
to an Internet transport medium. These methods are 
motivated by the desire to reduce high transport costs 
associated with Value-Added Networks (VAN's). Effec- 
tively, these methods diverge very little from traditional 
EDI. The same message formats, mapping software, 
and even enveloping constructs are employed. Use of 



4 

an open network, however, requires additional security, 
reliability and auditing capabilities that were formerly 
part of a VAN service. In addition, the use of these ad- 
ditional services in an open network configuration must 
s be supported by software at the endpoints of an infor- 
mation exchange. Internet-EDI, therefore, suffers from 
key limitations such as a lack of process support, an un- 
wieldy representation formalism, and an integration 
model that does not mesh with new practices. 
10 [0016] US 5,390,247 discloses a method and appa- 
ratures for creating a "traveling" program, including in- 
structions and associated data, which has the capability 
of determining at least one next destination and moving 
itself together with necessary associated data from one 
'5 computer user to another. In particular, D1 focuses on 
digital of authentication. 

[0017] US 5,557,780 discloses a programmable ma- 
chine system and method for performing electronic data 
interchange (EDI) among two or more trading partners, 
including receipt, manipulation and re-transmission of 
EDI structured data in any standard EDI format without 
the requirement of a template. 

[0018] DE 196 291 92 describes a communication 
system in which transmitter and receiver computers uti- 
lize both public and private key enkryption. Hashcodes 
are calculated for the electronic data interchange and 
incooperated in messages prior to private key encryp- 
tion. 

[0019] GB 2 271 002 deals with comparison of EDI, 
message based EDI, transaction based EDI and inter- 
active EDI. 

[0020] The approaches above fail to meet the increas- 
ing demand to implement between disparate systems 
complex, automated processes that are both secure 
and maintainable. Thus, a system and method to plan 
and control extended business interdependency are 
needed that (1) focuses specifically on peer-to-peer in- 
teractions among existing business application sys- 
tems, (2) supports secure and reliable communication, 
(3) minimizes custom software development, (4) has 
functionality to handle heterogeneous data representa- 
tion formalisms and (5) has the ability to support com- 
plex processes that extend into and out of enterprise ap- 
plications. 

[0021] The present invention provides a method for 
coordinating a process between a first site and a second 
site, comprising the features of claim 1 and a method 
for creating a process definition governing a process be- 
tween a first site and a second site comprising the fea- 
tures of claim 9. 

SUMMARY OF THE INVENTION 

[0022] The present invention is directed to methods 
for creating, executing, and maintaining cross-enter- 
prise processes! Cross-enterprise processes are 
shared automated business processes or workflows 
among distributed information systems that include spe- 
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cific provisions for automation of these processes 
across organizational boundaries and among heteroge- 
neous information systems. 

[0023] The system is comprised of a plurality of inde- 
pendent communicating subsystems called sites with 
common capabilities. Each of the sites includes a server 
with common means of representing and executing 
shared process definitions. These sites act in concert in 
the course of executing shared inter-system processes. 
Process execution comprises coordinated inter-site 
message exchanges that are coupled with controlled 
sequences of actions that are local to each of the sites. 
In addition, each site may include any one of a number 
of applications programs and operating systems for ex- 
ecuting the inter-system processes and internal proc- 
esses on the server. 

[0024] Automated inter-system processes are repre- 
sented in the methods of the present invention in a two- 
level process model. The top level or public process def- 
inition/module captures interactions among the inde- 
pendent sites (each typically representing an organiza- 
tion or business unit). Interactions include communica- 
tion events in which one site, designated in the public 
process definition by a node, sends a message of a 
known type to another site. The public process defini- 
tion, then, is a logical grouping or directed graph of in- 
terdependent communication events among a set of 
sites. Each definition specifies a set of valid sequences 
of communication events among the participating sites. 
[0025] Associated with any public process definition 
is a set of lower level or private process definitions or 
modules. A separate private process definition is bound 
to each node in a public process. The private process 
definition specifies a set of possible local actions that 
can be executed at the site when that particular public 
process node is executed. In the preferred embodiment, 
the private process definition is defined in terms of con- 
structs such as operating parameters and software ap- 
plication interactions specific to the node or site. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0026] Figure 1 is a block diagram of an extended en- 
terprise including a plurality of sites having public proc- 
ess definitions and private process definitions in accord- 
ance with the present invention. 
[0027] Figure 2 is a graphical representation of a pub- 
lic process definition including node, arcs and connec- 
tions between them in accordance with the present in- 
vention. 

[0028] Figure 3 is a flow diagram of the process for 
executing a private process definition in accordance 
with the present invention. 

[0029] Figure 4 is a block diagram of a system in ac- 
cordance with the present invention. 
[0030] Figure 5 is a flow diagram of a method for dis- 
tributing a public process definition in accordance with 
the present invention. 
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[0031] Figure 6 is a flow diagram of a method for the 
installation of a public process definition in accordance 
with the present invention. 

[0032] Figure 7 is a flow diagram of a method for ex- 
5 ecuting an instance of a specific process type in accord- 
ance with the present invention. 
[0033] Figure 8 is a graphical representation of a dis- 
play device showing a graphical user interface for edit- 
ting the public process definition. 
10 [0034] Figure 9 is a graphical representation of a dis- 
play device showing a graphical user interface for edit- 
ting the private process definition. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0035] Referring to Figure 1 , a preferred embodiment 
of an extended enterprise system 1 00 is shown. The ex- 
tended enterprise system 1 00 of the preferred embodi- 
ment of the present invention preferably comprises a 
plurality of sites 101, 102 and 103 installed at distinct 
organizations that are coupled by a communications 
network 1 04. These sites 1 01 -1 03 form an extended en- 
terprise 100 in which the internal processes of each site 
1 01 -1 03 are coupled with the internal processes of other 
sites 1 01 -1 03 via coordinated sequences of information 
exchanges. For example, sites 101-103 may be busi- 
ness enterprises that comprise three elements of a sup- 
ply chain: supplier, manufacturer and customer. Those 
skilled in the art, however, will recognize that the sites 
101-103 could for any type of business unit or function, 
that there may be any number of site, and three sites 
101-103 are provided only by way of example. 
[0036] Each of these sites 1 01 -1 03 represents a zone 
of control and is comprised by a set of application sys- 
tems that store information and contain logic for retriev- 
ing and modifying that information. Example applica- 
tions include ERP (Enterprise Resource Planning) ap- 
plication suites, Product Data Management (PDM) sys- 
tems, logistics applications, and advanced planning 
systems (APS). 

[0037] Operation of the present invention includes co- 
ordinated sequences of actions within each site 1 01 -1 03 
that are linked with coordinated sequences of informa- 
tion exchanges among different sitesl 01 -1 03. The ac- 
tions executed within each site 101-103 include prima- 
rily the movement of information into and out of the ap- 
plications associated with sites 101-103. Each ex- 
change of information between sites 1 01 -103 is preced- 
ed by a sequence of actions within the sending site and 
is followed by another sequence of actions within the 
receiving site. Accordingly, these site-specific sequenc- 
es of actions serve as the connections that bind a set of 
information exchanges into a single coordinated se- 
quence of interactions. 

[0038] The possible sequences of local actions and 
site to site exchanges are specified through a process 
definition language. This language allows for complex 
branching and looping logic and can capture constraints 
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that govern the relationships between local action se- 
quences and site to site exchanges. More formally, the 
process definition language of the preferred embodi- 
ment includes node and arc elements that are combined 
with a specific ordering and logic to create a directed 
graph (such as depicted in Figure 2 and as will be de- 
scribed below). A single source node 205-225 and a sin- 
gle destination node 205-225 define each arc element. 
Each node 205-225 includes a set of input arcs and as- 
sociated logic connecting it to antecedent nodes 
205-225 and a set of output arcs and associated logic 
connecting it to consequent nodes 205-225. The rela- 
tionship between the input arcs for a given node 
205-225 is defined by a logical sentence, containing 
possibly nested conjunctive and disjunctive proposition- 
al connectives, in which each arc is represented by a 
distinct propositional symbol. The output arcs for a given 
node are related by a separate logical sentence of 
equivalent form. Node 201 has no input arcs and is re- 
ferred to as an initial node. Nodes 299 that have no out- 
put arcs are referred to as terminal nodes. 
[0039] In the preferred embodiment, a two-level proc- 
ess model is used to represent the collection of site-to- 
site information exchanges and site-specific sequences 
of actions. A public process definition or module 116a 
specifies the relationship between all site-to-site infor- 
mation exchanges. The sequence of possible actions 
within a single site 101, 1 02, 1 03, for a particular node 
in a public process definition 1 1 6a, is specified by a pri- 
vate process definition or module 118a, 118b, 118c. 
Both the public and private process definitions 116a, 
1 1 8a, 1 1 8b, 1 1 8c are built on top of the process definition 
language with special interpretations for node 205-225 
and arc elements. In a public process definition 116a, 
each node element represents a specific site 101 , 102, 
103 and each arc element represents a message with 
specific information contents that are sent from the site 
101 , 102, 103, represented by the arc's source node to 
the site represented by the arc's destination node. The 
graph for a public process can include only a single initial 
node. The public process definition 116a, then, is a 
specification of "who does what when" among a set of 
sites 101 -103 for a particular purpose. Each public proc- 
ess definition 1 1 6a specifies a set of valid sequences of 
communication events among the participating sites 
101, 1 02, 1 03. More specifically, the same public proc- 
ess definition 116a is provided to each site 101, 102, 
103 having an action in the public process definition 
1 1 6a. As shown in Figure 1 , each site 1 01 , 1 02, 1 03 may 
have one or more public process definitions 116a, one 
for each inter-site process. In a private process defini- 
tion 1 1 8a, 1 1 8b, 1 1 8c, node elements represent specific 
programmatic actions and arc elements specify the or- 
der in which these actions are executed. The private 
process definition 118a, 118b, 118c specifies how sites 
101-103 process received messages and construct out- 
going messages. Moreover, private process definitions 
1 1 8a, 1 1 8b, 1 1 8c specify what happens within a node of 
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public process definition 1 1 6a. Thus, the private process 
definitions 118a, 118b t 118c include routines and proc- 
esses that are tailored to the particular site 101, 102, 
1 03 to which the private process definitions 1 1 8a, 1 1 8b, 

5 1 1 8c is assigned or operates upon. Still more particular- 
ly, the private process definitions 118a, 118b ( 118c are 
designed for interaction using the operating systems, 
applications and resources of the site to which it is as- 
signed. Thus, as depicted in Figure 1 each of the private 

10 process definitions 118a, 118b, 11 8c is different for each 
site 101, 102, 103. Nonetheless, when sites 101, 102, 
103 are similarly configured (e.g., have the same oper- 
ating systems, applications and resources) the private 
process definitions 118a, 118b, 118c may be used or 

15 shared. Those skilled in the art will recognize that each 
site 101 , 102, 1 03 may also include a plurality of private 
process definitions 118a, 118b, 118c as depicted in Fig- 
ure 1 , The plurality of private process definitions 118a, 
118b, 11 8c may be for one public process definition 116a 

20 or different public process definitions 1 1 6a. 

[0040] The preferred embodiment models the infor- 
mation contained in the messages sent between sites 
1 01 , 1 02 and 1 03 as objects with restricted structure and 
behaviors. These objects are data containers whose 

25 possible contents are specified by object definitions 
120a, 120b, 120c. In the preferred embodiment, an ob- 
ject definition 120a, 120b, 120c takes the form of an 
XML (Extensible Markup Language) DTD (Document 
Type Definition). This definition specifies the lexical and 

30 grammatical form of all objects of that type. Object def- 
initions 120a, 120b, 120c are referenced by both public 
and private process definitions. 
[0041 ] Referring now to Figure 2, an exemplary public 
process definition 200 is shown. The public process def- 

35 inition 200 is represented graphically as a flow chart. 
Figure 2 shows a public process definition 200 that 
specifies a set of possible interactions among sites 
101-103. Process 200 comprises a set of nodes 205 
through 225 and a set of communication events 230 

40 through 250. Each node corresponds with a specific site 
101-103, and associated with each node 205 through 
225 of public process definition 200 is a private process 
definition 11 8a,, 118b, 118c. Figure 3 shows an exem- 
plary private process definition 300 associated with 

45 node 210. 

[0042] Each communication event 230-250 that con- 
nects one node to another in a public process definition 
200 represents the exchange of a message of a known 
object type. For example, the known objects may be any 

so one of the conventional types of business objects such 
as a purchase order object, an confirmation messages 
object, etc. Such objects 120a, 120b, 120c are defined 
in the object definition 120a, 120b, 120c so that each 
site 1 01 , 1 02, 1 03 may use the object definitions 1 20a, 

55 120b, 120c as needed to process objects on either the 
public level or the private level. In other words, public 
process definition 200 is a logical grouping or a directed 
graph of interdependent communication events 
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230-250 among the sites 101-103 shown in Figure 1. 
This grouping specifies a set of valid sequences of com- 
munication events among the participating sites 101, 
102, 103. Specifically, public process definition 200 de- 
scribes at communication event 230 a purchase order 
sent from site 101 to site 102. This purchase order is 
generated by the private process of site 1 01 associated 
with node 205, Node 210 is a branching node, and two 
communication events, 235 and 240, are produced at 
that node. Depending on a specified branch condition, 
either one of the events occurs or both events occur. 
The conditions under which these two events trigger are 
not indicated by public definition 200, since they are 
known only to the site 102. These conditions are con- 
tained in private process definition 1 1 8b associated with 
node 210, and thus site 1 02. Those skilled in the art will 
also recognize that the private process definition 118b 
may be a set of private process definitions that corre- 
spond to an instance of a public process definition 1 1 6a. 
[0043] The occurrence of events 235 and/or 240 
causes the execution of the node{s) that immediately 
follow and execution proceeds downward on the Figure. 
Node 225 represents a branch junction node that can 
wait for one or all events of a set that connect to it. Fol- 
lowing execution of node 225 the public process termi- 
nates at terminal 299. 

[0044] Associated with each node 205 through 225 of 
public process definition 200 is a private process defini- 
tion 118a, 118b, 118c. For example, Figure 3 shows a 
private process definition 300 associated with node 21 0. 
Unlike the public process definition 200, the content of 
private process definition 300 is determined and known 
solely by the corresponding site, site 102 in this case. 
Private process definition 300 includes a number of ac- 
tions 305 through 330 that are controlled according to a 
specified logic. Possible actions include external busi- 
ness application interactions, script execution, user no- 
tification and approval, time delay, output object speci- 
fication, and sub-process execution. All instances of the 
private process definition 300 have access to the object 
of type 'Purchase Order* that is contained in communi- 
cation event 230. Any action in private process definition 
300 can reference this object. Private process definition 

300 is constrained to produce a object either of type 'Ac- 
knowledgment' or of type 'Purchase Order 4 correspond- 
ing to communication events 235 and 240 respectively. 
[0045] Referring now to Figure 3, one exemplary em- 
bodiment for a private process definition 300 is shown. 
Private process definition 300 begins at initiator action 

301 that executes after communication event 230 com- 
pletes. Those skilled in the art will recognize that the 
process would be similar for a variety of other private 
process definitions such that once the object is trans- 
ferred to or received by the site 101, 102, 103, the pri- 
vate definition corresponding to the node following the 
communication event is automatically started. Private 
process 300 continues to action 305. Action 305 execu- 
tion entails posting an information block corresponding 
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to the received purchase order into business application 
113. Following completion of action 305 execution con- 
tinues to action 310. Action 310 entails querying busi- 
ness application 114 to determine if the item associated 

5 with the Purchase Order of communication event 230 is 
locally stocked or if the item is outsourced. The result of 
this query is put into a variable named 'OUTSOURCED' 
in a set of variables associated with private process 300. 
Action 31 5 is executed subsequent to action 31 0. Action 

10 315 entails an IF-THEN-ELSE conditional test on the 
value of OUTSOURCED inside of a script action: Re- 
sults of this conditional test determine whether path A 
or path B is followed subsequent to action 315 comple- 
tion. Path A execution proceeds to action 320, which en- 

15 tails the construction of a object of type "Acknowledg- 
ment' and its designation as an output of the private 
process. Path B execution proceeds to action 325, 
which entails the construction of a object of type 'Pur- 
chase Order* and its designation as an output of the pri- 

20 vate process. Paths A and B terminate in action 330, 
which entails notification of a designated user via elec- 
tronic mail of certain status information associated with 
the running process. This information includes identify- 
ing characteristics of the purchase order and results of 

25 business application queries. Following execution of ac- 
tion 330, the private process terminates, and control re- 
turns to the public process level. The use of such private 
definitions is particularly advantages because it pro- 
vides uniform control and regulation of the inter-site 

30 processes, while allowing maximum flexibility through 
the use of private definitions that allows the controller of 
a particular site to implement the private definition in any 
number of ways according to parameters, resources, 
and other constraints for a particular site. 

35 [0046] Each site of the preferred embodiment in- 
cludes a combination of components that support the 
design, implementation and maintenance of public and 
private processes and the runtime components that 
support the execution of these processes. Figure 4 

40 shows the preferred configuration of an example site 
102. 

[0047] The standard site 1 02 is comprised by a single 
server 480 and one or more clients 460, 470 that com- 
municate with the server over a network 409. Clients 

45 460 and 470 and server 480 run on separate host com- 
puters. Clients 460 and 470 contain graphical user in- 
terfaces (GUI's) 465 and 475 respectively. In addition, 
server 480 includes or has access to database 41 0 and 
applications 420 and 430. In the preferred embodiment, 

50 database 41 0 resides on a host computer that is sepa- 
rate from the one on which server 480 is located.Clients 
460 and 470 and server 480 share common represen- 
tations of relevant information by interacting over net- 
work 409 according to a specified and conventional 

55 communication protocol. Such shared information rep- 
resentations include public and private process defini- 
tions, object definitions, process execution histories, as 
well as information about other sites with which the site 
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interacts. Human users 440 and 450 interact with site 
102 via client GUI's 465 and 475 to view, create, edit, 
and manage the shared information representations de- 
limited above. For example, users 440 and 450 are able 
to view and edit graphical representations of public proc- 
ess 200 and private process 300 on GUI's 465 and 475. 
Figures 8 and 9 shown a screen shot of the GUIs cor- 
responding to the public and private process definition 
described above with reference to Figures 2 and 3, re- 
. spectively. 

[0048] The server 480 of the preferred embodiment is 
comprised of a middle-tier manager set 482, an execu- 
tion engine 484, a transport manager 486 and adapters 
488 and 489. The middle-tier manager set 482 controls 
the access and flow of information between network 
409, engine 484, and database 410. In addition, it im- 
plements associated application logic, and insures the 
consistency of information between these elements. 
With respect to network 409, set 482 mediates access 
to information from concurrently operating clients and 
other components of server 480. 
[0049] As discussed in detail below, the installation of 
public and private processes 200 and 300 requires the 
prior approval of user 440 or 450. Once this approval is 
received, it is entered by the appropriate user into client 
460 or 470 via the respective GUI. A local install signal 
is then relayed over network 409 to server 480. Manager 
set 482, acting upon the received signal, initiates the 
installation of the process definitions into engine 484. 
During installation, the execution engine 484 transforms 
the process definitions it receives into executable state 
machines which are saved in database 41 0. This trans- 
formation extracts from the public process definition all 
nodes connected to arcs involving the target site. The 
resulting state machine contains all information neces- 
sary for a single site to participate in the execution of 
the original public process. Once the installation is com- 
plete, manager set 482 provides engine 484 with any 
additional information stored in database 410 or re- 
ceived from clients 460 and 470 needed to perform proc- 
ess execution. Persistence of shared data is maintained 
by communication with database 410. 
[0050] Once the installation of private and public proc- 
ess definitions 200 and 300 is complete, engine 484 
controls their execution.. During execution, the execu- 
tion engine 484 manages two key activities: inbound 
and outbound communication with other sites via trans- 
port manager 486 and interactions with applications 420 
and 430 via adapters 488 and 489. The engine 484 also 
manages through manager set 482 several auxiliary ac- 
tivities including the sending and receiving of messages 
to and from users 440 and 450 and the storage of log 
information in database 410. 

[0051] During the execution of a public process defi- 
nition, such as definition 200, transport manager 486 
manages communications to and from Internet 1 04. For 
example, public process definition 200 anticipates the 
reception of purchase order 230 and acknowledgment 
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245 by site 102, as well as the sending of acknowledg- 
ment 235 and purchase order 240. In this capacity, man- 
ager 486 preferably handles retry and acknowledgment 
logic (based on the properties of the service it is using). 
5 Messages are created outside of any specific transport 
service and communication security is message based. 
Non-repudiation receipts for both origin and delivery are 
supported, 

[0052] During execution, adapters 488 and 489 me- 

'0 diate the flow of data between the execution engine 484 
and external applications 420 and 430. For example, re- 
ferring to step 315 of private process definition 300, en- 
gine 484 may transmit a request through adapter 488 
or 489 that application 420 or 430 determine whether 

*5 the item in question is outsourced. In turn, the applica- . 
tion will respond through the respective adapter. Adapt- 
er configuration options for 488 and 489 are set by au- 
thors of private processes for the associated site. These 
adapters 488 and 489 communicate their acceptable 

20 configuration options to the middle-tier manager set 482 
at the time of their installation. The configuration inter- 
face for adapters 488 and 489 allows a private process 
to insert data into an external application, retrieve data 
from an external application or listen for a specific event 

25 produced by the external application,, where the insert- 
ed, retrieved or listened for data is represented by an 
object definition. Adapters 488 and 489 also insure uni- 
form properties of state/consistency management and 
auditing behavior across the different applications that 

30 can be integrated with the system. During process exe- 
cution, adapters 488 and 489 map the insertion, retrieval 
and listened for actions specified in a private process 
into specific interactions with target applications 420 
and 430. 

35 [0053] Operation of a site of the preferred embodi- 
ment revolves around the life cycle of a public process 
definition and the associated private process and object 
definitions. Shown in figure 5, this cycle begins with the 
creation of a public process definition and referenced 

40 object definitions then continues with the distribution of 
the public process definition and object definitions, cre- 
ation of the necessary private process definitions, instal- 
lation of the process, and ends with process execution. 
[0054] In step 502, the user creates a public process 

45 definition. The site at which the public process definition 
200 is created is referred to as the authoring site. Cre- 
ation of the public process definition 200 includes the 
creation of all object definitions that represent site-to- 
site messages in the public process definition. In the 

so preferred embodiment, both public process and object 
definitions are created by users 440 and 450 interacting 
with manager set 482 through client GUI's 465 and 475. 
During creation of public process definition 200, for ex- 
ample, user 440 specifies the sequence of interactions 

55 among all participating sites 101 , 1 02 and 1 03 and the 
logic connecting these interactions. In this example, GUI 
465 would present definition 200 as a set of icons inter- 
connected by flow indicators that would appear much 
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as the diagram in figure 2. Definitions for the purchase 
order, acknowledgment and rejection objects would also 
be created by user 440 via GUI 465 if they did not pre- 
exist. 

[0055] After the public process and necessary objects 
have been defined, the user proceeds with distribution 
of the process. In step 504, the authoring site sends over 
the internet 104, the authored public process definition 
and referenced object definitions to all sites participating 
in the public process. Those skilled in the art will recog- 
nize that internet 1 04 may be a intranet on a local area 
network (LAN), an internet on a wide area network 
(WAN), or the Internet. In this case, site 102 is the au- 
thoring site and sites 101 and 103 are the participant 
sites. In order for site 102 to send public process defi- 
nition 200 and associated object definitions over the In- 
ternet, the definitions are sent from manager set 482 to 
transport manager 486 and from there to the transport 
managers of the participant sites. Upon receipt of public 
process definition 200 and object definitions by the par- 
ticipant site transport managers, in this case sites 101 
and 103, the definitions are passed from the transport 
manager to the middle-tier managers for persistent stor- 
age in the site database. After reviewing received public 
process definition 200 and object definitions via a client 
GUI, users at the participant sites 1 01 and 1 03 must ap- 
prove or disapprove the public process definition, said 
approval or disapproval being sent via the transport 
managers of the partner sites to the authoring site. While 
public process definition 200 is being reviewed at par- 
ticipant sites 101 and 103, authoring site 102 waits for 
the approval or disapproval votes to' be received by 
transport manager 486 in step 508. The approval or dis- 
approval by sites 101 and 103 is likely to turn on com- 
mercial, rather than technical, concerns. If a partner site 
finds the commercial arrangements described in defini- 
tion 200 acceptable, it returns an approval signal to the 
authoring site, in this case site 1 02. In step 508, the sys- 
tem tests for universal approval, if either participant site 
101 or 1 03 disapproves of public process 200, authoring 
site 102 will distribute an abort message through trans- 
port manager 486 to partner sites 101 and 103, thus 
reaching step 51 0. In this case, public process definition 
200 is abandoned and sites 101, 1 02 and 1 03 may start 
negotiating for a new public process definition. If the 
public process definition is universally accepted in step 
508, the authoring site 102 distributes a commit mes- 
sage to each of the partner sites . 
[0056] After the commit messages have been trans- 
mitted by the authoring site and received by the partic- 
ipant sites, both the authoring site and participant sites 
proceed with creation of the private processes associ- 
ated with the public process nodes owned by each site. 
This is represented by step 514 in figure 5. Each site 
user creates a private process definition for each node 
of the public process definition associated with the us- 
er's site. For example, user 440, creates private process 
definition 300 for node 210 and an accompanying pri- 



vate process definition for node 220, since nodes 210 
and 220 are each associated with site 102. Likewise, a 
user at site 1 01 would create private process definitions 
for nodes 205 and 225, while a user at site 103 would 

5 create a definition for node 215. 

[0057] After successfu lly implementing the necessary 
private process definitions, each participant site sends 
a message to the authoring site signally the completion 
of private process implementation. In step 516, the au- 

10 thoring site gathers private process completion signals 
from all sites. If any site fails to implement one or more 
private processes, it will send a failure message to the 
authoring site. In this case, the implementation process 
will be aborted (step 518), and process definition 200 

*5 will be abandoned. Once the authoring site has received 
messages from all participant sites indicating successful 
private process implementation, and has successfully 
implemented its own private processes, the authoring 
site can begin the installation process (step 520). 

20 [0058] Process installation (step 520) begins with the 
authoring site sending installation messages to all par- 
ticipant sites. After receiving the installation message, 
each participant site locally installs the public process. 
Figure 6 shows a flow diagram of a process for installing 

25 at a single site the private process definitions associated 
with a public process definition. In step 602, the public 
process definition and associated private process defi- 
nitions are passed from manager set 482 to execution 
engine 484. In step 604, the public process definition is 

30 compiled to produce a state machine that contains 
states only for the site in question. For example, the 
process of compiling public process definition 200 at site 
102 will result in states associated with nodes 210 and 
220. Recorded in the state machine is a triggering event 

35 for each state. Continuing with the example of public 
process definition 200, site 102 records that event 230, 
a purchase order from site 101, triggers the state asso- 
ciated with node 210, and that event 245, an acknowl- 
edgment from site 103, triggers the state associated 

to with node 220. In step 606, each state of the state ma- 
chine is bound by a "call" command with an associated 
private process definition. For example, site 102 will 
bind private process definition 300 with the state asso- 
ciated with node 210. The result of this binding is that 

45 when the state associated with node 21 0 is triggered by 
a purchase order from site 101 , private process defini- 
tion 300 is called and executed. In step 608 t a determi- 
nation is made as to whether the site in question is the 
initiator of the public process. If not, as in the example 

50 of site 1 02, the execution engine determines the trigger- 
ing message to be received and registers it in the trans- 
port manager. In the example of site 1 02, the two trig- 
gering messages are purchase order 230 from site 101 
and acknowledgment 245 from site 1 03. If the site is the 

55 initiator of a public process, the triggering event for the 
first private process is internal to the site and is regis- 
tered in step 612 as an event trigger, a scheduled star- 
tup, or as a subprocess trigger. 
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[0059J After successfully installing the public process, 
each participant site sends an installation confirmation 
message back to the authoring site. In step 522, the au- 
thoring site collects installation confirmation messages 
from all participant sites. If any site is unable to install 
the public process, the process is aborted 524 as de- 
scribed above. Successful installation at the authoring 
site triggers the transmission of messages to all partic- 
ipants indicating that the public process has been in- 
stalled at all involved sites. At this point the process is 
ready for execution (step 526). 
[0060] As discussed above, the execution of a public 
process is actually performed by the interactive execu- 
tions of the associated private processes at the partner 
sites. The execution of an installed public process by a 
single site is shown in figure 7. Execution begins in step 
702 with an initiating event that can include the follow- 
ing: receipt of a message from a partner site, an event 
associated with an application, a scheduled startup, or 
a subprocess trigger. For example, node 210, of public 
process definition 200, is triggered by the receipt of a 
purchase order message from site 1 01 . In step 704, the 
execution engine at the triggered site creates an in- 
stance in the appropriate state machine and sets the 
machine to the initial state. In step 706, the execution 
engine fetches the private process associated with the 
associated public process node. For example, upon the 
triggering of node 210, private process definition 300 is 
accessed. In step 708, the execution engine passes ap- 
propriate data including the contents of the event 230 to 
the private process and initiates its execution. In step 
710, the private process executes and returns data to 
the execution engine, and in step 71 2, the execution en- 
gine acts upon the basis of the returned data. For ex- 
ample, private process 300 returns to execution engine 
484 either an instruction to send an acknowledgment to 
site 101 or a purchase order to site 103. It is noted that 
during the execution of the private process in step 71 0, 
engine 484 may make use of applications 420 and 430. 
Execution engine 484 responds accordingly. In step 
714, a determination is made by the execution engine 
as to whether a local terminal state of the public process 
definition has been reached. This determination is a lo- 
cal determination and is limited to the participation of 
the site in the public process. For example, the comple- 
tion of node 220 is a local terminal state for site 102, 
since it is the final node in process 200 that corresponds 
with site 102. Likewise, depending on the outcome of 
the accompanying private process, the completion of 
node 210 may be a local terminal state for site 102. If 
local termination is encountered, the public process 
ends for the site in step 716. Step 71 6 is not complete 
until a two-phase commit protocol has been executed 
among sites 101, 102, and 103 ensuring mutual com- 
pletion of process 200 execution. 
[0061] If the local terminal state is not encountered in 
step 714, the transport manager waits for triggering 
messages from partner sites (step 718). For example, 



if the result of node 21 0 is the transmission of a purchase 
order in event 240, transport manager 486 waits for the 

• acknowledgment of event 245 to trigger the private proc- 
ess associated with node 220. Once the triggering mes- 

s sage is received in step 720, the execution engine looks 
up the associated process state in step 722. The private 
process then begins execution at step 706 and is per- 
formed as described above. 



Claims 

1 . A method for coordinating a process between a first 
site and a second site in a distributed information 
system using a public process definition (116a) 
comprised of a first node (205) associated with the 
first site (101), a second node (210) associated with 
the second site (102) and an arc connected to the 
first and second nodes (205, 21 0), the method com- 
prising: 

executing the first node (205) of the public proc- 
ess definition (116a) at the first site (1 01 ) by ex- 
ecuting a first private process definition (118a) 
associated by shared information with the first 
node (205); and, 

upon receiving the message defined by the arc, 
executing the second node (210) of the public 
process definition (116a) at the second site 
(102) by executing a second private process 
definition (118b) associated by shared informa- 
tion with the second node (210). 

2. The method of claim 1 , wherein the arc is a business 
object (120). 

3. The method of claim 1 or 2, further comprising: 

at the first site (101), creating (502) the public 
process definition (116a); 
distributing (504) the public process definition 
(11 6a) to the second site (102); 
at the first site (101), associating with the first 
node (205) by shared information a first private 
• process definition (118a), containing an action 
preceding the transmission of the message 
from the first site (101); and, 
at the second site (102), associating with the 
second node (210) by shared information a 
second private process definition (118b) con- 
taining an action following the reception of the 
message by the second site (1 02). 

4. The method of claim 3, wherein the step of distrib- 
uting (504) further comprises: 

reviewing the public process definition (116a) 
at the second site (1 02); and, 
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in the event of an approval of the public process 
definition (1 1 6a) at the second site (1 02), trans- 
mitting an approval signal from the second site 
(102) to the first site (101); and, 
in the event of a disapproval of the public proc- 
ess definition (116a) at the second site (102), 
transmitting a disapproval signal from the sec- 
ond site (102) to the first site (101). 

The method of claim 3 or 4, wherein the step of dis- 
tributing (504) further comprises: 

in the event of receiving at the first site (1 01 ) an 
approval signal from the second site (102), 
transmitting a commit message to the second 
site (102); 

installing the public process definition (116a) 
and the first private process definition (1 1 8a) at 
the first site (101); and, 
in the event of receiving at the second site (1 02) 
the commit message from the first site (101), 
installing the public process definition (116a) 
and the second private process definition 
(118b) at the second site (1 02). 

The method of claim 3, 4 or 5, wherein the step of 
distributing (504) further comprises: 
in the event of receiving at the first site (1 01 ) a dis- 
approval signal from the second site (102), trans- 
mitting an abort message to the second site (102). 

The method of one of the preceding claims, further 
comprising: 



w 



15 



20 



25 



30 



creating (502) at the first site (101) apublic 
process definition (116a) including a first node 
(205) associated with the first site (1 01 ), a sec- 
ond node (21 0) associated with the second site 
(1 02), and an arc (1 20) interposed between the 
first node and the second node; 
distributing (504) the public process definition 
(116a) to the second site (102); 
creating (514) at the first site (1 01 ) a first private 
process definition (118a) associated by shared 
information with the first node (205) and in 
which an action preceding the transmission of 
the message from the first site (101) is defined; 
and, 

creating (514) at the second site (1 02) a second 
private process definition (11 8b) associated by 
shared information with the second node (210) 
and in which an action following the reception 
of the message by the second site (1 02) is de- 
fined. 

10. The method of claim 9, further comprising: 

executing the first node (205) of the public proc- 
ess definition (116a) by executing the first pri- 
vate process definition (11 8a). at the first site 

(101) ; and 

upon receiving the message, executing the 
second node (210) of the public process defini- 
tion (116a) by executing the second private 
process definition (118b) at the second site 

(102) . 



at the first site (101), transforming the public 
process definition (116a) into a first state ma- 
chine; and, 

at the second site (1 02) , transforming the public 
process definition (116a) into a second state 
machine. 

8. The method of one of the preceding claims, further 
comprising: 

recording in a first process execution history 
the execution of the first node (205) of the pub- 
lic process definition (116a): 
recording in a second process execution histo- 
ry the execution of the second node (210) of 
the public process definition (116a): 
auditing the first and second process execution 
histories. 

9. A method for creating a process definition govern- 
ing a process between a first site (101) and a sec- 
ond site in a distributed information system (102) 
the method comprising: 
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Verfahren zum Koordinieren des Prozesses zwi- 
schen einer ersten Stelle und einer zweiten Stelle 
in einem verteilten Informationssystem unter Ver- 
wendung einer offentlichen ProzeBdefinition 
(1 1 6a), welche einen der ersten Stelle (101) zuge- 
ordneten ersten Knoten (205), einen der zweiten 
Stelle (102) zugeordneten zweiten Knoten (210) 
und einen mit dem ersten und dem zweiten Knoten 
(205, 210) verbundenen Bogen umfaBt, mit folgen- 
den Verfahrensschritten: 

Ausfiihren des ersten Knotens (205) der offentli- 
chen ProzeBdefinition (116a) bei der ersten Stelle 
(101) durch Ausfuhren einer ersten privaten Pro- 
zeBdefinition (118a), die dem ersten Knoten (205) 
durch gemeinsam genutzte Information zugeordnet 
wird; und bei Empfang der durch den Bogen defi- 
nierten Nachricht, Ausfuhren des zweiten Knotens 
(210) der offentlichen ProzeBdefinition (116a) bei 
der zweiten Stelle (102) durch Ausfuhren einer 
zweiten privaten ProzeBdefinition (118b), die dem 
zweiten Knoten (210) durch gemeinsam genutzte 
Information zugeordnet wird. 
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Verfahren nach Anspruch 3, wobei der Schritt des 
Verteilens (504) die folgenden weiteren Schritte 
umfaBt: 

Durchsehen der offentlichen Proze3definition 
(116a) bei derzweiten Stelle (102); und 
wenn die offentliche ProzeBdefinition (116a) 
bei der zweiten Stelle (102) bestatigt 
wird, Ubertragen eines Bestatigungssignals 
von derzweiten Stelle (102) an die erste Stelle 
(101); und 

wenn die offentliche ProzeBdefinition (116a) 
bei der zweiten Stelle (1 02) nicht bestatigt wird, 
Ubertragen eines Nicht-Bestatigungssignals 
von derzweiten Stelle (102) an die erste Stelle 

(101) . 

Verfahren nach Anspruch 3 oder 4, wobei der 
Schritt des Verteilens (504) die weiteren Schritte 
umfaBt: 

wenn bei der ersten Stelle (101) ein Bestati- 
gungsstgnal von derzweiten Stelle (102) emp- 
fangen wird, Ubertragen einer Ausfuhrungs- 
nachricht an die zweite Stelle (102); 
Installieren der offentlichen ProzeBdefinition 
(116a) und der ersten privaten ProzeBdefinition 
(118a) bei der ersten Stelle (101); und 
falls die Ausfiihrungsnachricht von der ersten 
Stelle (101) bei der zweiten Stelle (102) emp- 
fangen wird, Installieren der offentlichen Pro- 
zeBdefinition (116a) und der zweiten privaten 
ProzeBdefinition (118b) bei der zweiten Stelle 

(102) . 
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Verfahren nach Anspruch 1, wobei der Bogen ein 
Geschaftsobjekt (120) ist. 

Verfahren nach Anspruch 1 oder 2, mit den weiteren 
Verfahrensschritten: 5 



Erzeugen (502) der offentlichen ProzeBdefini- 
tion (116a) bei der ersten Stelle (101); 
Weitergeben (504) der offentlichen ProzeBde- 
finition (116a) zu der zweiten Stelle (102); 
wobei bei der ersten Stelle (101) dem ersten 
Knoten (205) durch gemeinsam genutzte Infor- 
mation eine erste private ProzeBdefinition 
(1 1 8a) zugeordnet wird, die eine Aktion umfaBt, 
welche der Obertragung der Nachricht von der 
ersten Stelle (105) vorhergeht; und 
wobei bei der zweiten Stelle (1 02) dem zweiten 
Knoten (210) durch gemeinsam genutzte Infor- 
mation eine zweite private ProzeBdefinition 
(118b) zugeordnet wird, die eine Aktion umfaBt, 
die dem Empfang der Nachricht an der zweiten 
Stelle (102) folgt. 
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6. Verfahren nach Anspruch 3, 4 oder 5, wobei der 
Schritt des Verteilens (504) die weiteren Schritte 
umfaBt: 

falls bei der ersten Stelle (101) ein Nicht-Bestati- 
gungssignal der zweiten Stelle (102) empfangen 
wird, Ubertragen einer Abbruchnachricht an die 
zweite Stelle (102). 

7. Verfahren nach einem der vorangehenden Anspru- 
che, bei dem 

bei der ersten Stelle (101) die offentliche Pro- 
zeBdefinition (116a) in eine erste Ablaufsteue- 
rung transformiert wird und 
bei der zweiten Stelle (1 02) die offentliche Pro- 
zeBdefinition (116a) in eine zweite Ablauf- 
steuerung transformiert wird. 

8. Verfahren nach einem der vorangehenden Ansprii- 
che, bei dem 

die Ausfuhrung des ersten Knotens (205) der 
offentlichen ProzeBdefinition (11 6a) in einer er- 
sten ProzeBausfiihrungsaufzeichnung aufge- 
zeichnet wird; 

die Ausfuhrung des zweiten Knotens (21 0) der 
offentlichen ProzeBdefinition (116a) in einer 
zweiten ProzeBausfiihrungsaufzeichnung auf- 
gezeichnet wird, 

die erste und die zweite ProzeBausfiihrungs- 
aufzeichnung geiibt werden. 

9. Verfahren zum Erzeugen einer ProzeBdefinition zur 
Kontrolle eines Prozesses zwischen einer ersten 
Stelle (101) und einer zweiten Stelle (102) in einem 
verteilten Informationssystem, mit folgenden Ver- 
fahrensschritten: 

Erzeugen (502) einer offentlichen ProzeBdefi- 
nition (116a) bei der ersten Stelle (101), mit ei- 
nem der ersten Stelle (101) zugeordneten er- 
sten Knoten (205), einem der zweiten Stelle 
(102) zugeordneten zweiten Knoten (201) und 
einem Bogen (120), der zwischen dem ersten 
Knoten und dem zweiten Knoten liegt; 
Weitergeben (504) der offentlichen ProzeBde- 
finition (1 1 6a) an die zweite Stelle (1 02); 
Erzeugen (514) einer ersten privaten 
ProzeBdefinition (118a) bei der ersten Stelle, 
die mittels gemeinsam genutzter Information 
dem ersten Knoten (205) zugeordnet wird, wo- 
bei eine der Obertragung der Nachricht von der 
ersten Stelle (102) vorangehende Aktion defi- 
niert wird; 

Erzeugen (514) einer zweiten privaten 
ProzeBdefinition (118) bei der zweiten Stelle, 
welche mittels gemeinsam genutzter Informa- 
tion dem zweiten Knoten (210) zugeordnet 
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wird, wobei eine dem Empfang der Nachricht 
bei der zweiten Stelle (1 02) folgende Aktion de- 
finiert wird. 

10. Verfahren nach Anspruch 9, bei dem 

der erste Knoten (205) der offentlichen 
ProzeBdefinition (1 1 6a) ausgefuhrt wird, indem 
die erste private ProzeBdef inition (1 1 8a) bei der 
ersten Stelle (102) ausgefuhrt wird; und 
beim Empfang der Nachricht der zweite Knoten 
(210) der offentlichen ProzeGdefinition (116a) 
ausgefuhrt wird, indem die zweite private Pro- 
ze3definition (118b) bei der zweiten Stelle 
(1 02) ausgefuhrt wird. 



Revendications 

1. Procede de coordination d'un processus entre un 
premier site et u n second site dans un systeme d'in- 
formations reparti, utilisant une definition publique 
(116a) du processus comprenantun premier noeud 

' (205) associe au premier site (101) et un second 
noeud (21 0) associe au second site (1 02) et un arc 
connecte aux premier et second noeuds (205, 210), 
ce procede comprenant les etapes suivantes : 

executer le premier noeud (205) de la definition 
publique (1 1 6a) du processus au niveau du pre- 
mier site (101) en executant une premiere de- 
finition privee (118a) du processus associee 
par des informations partagees au premier 
noeud (205) ; et 

a la suite de la reception du message defini par 
Tare, ex£cuter le second noeud (21 0) de la de- 
finition publique (1 1 6a) du processus au niveau 
du second site (1 02) en executant une seconde 
definition privee (118b) du processus associee 
par des informations partagees au second 
noeud (210). 

2. Procede selon la revendication 1 , dans lequel Tare 
est un objet de travail (120). 

3. Proc6de selon la revendication 1 ou 2, comprenant 
en outre : 

au niveau du premier site (101), 

creer (502) la definition publique (1 1 6a) du 
processus ; 

r6partir (504) la definition publique (116a) 
du processus vers le second site (102) ; 
associer au premier noeud (205) par des 
informations partagees une premiere defi- 
nition privee (118a) du processus conte- 
nant une action pr6c6dant la transmission 
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5. 



du message a partir du premier site (101); 
et 

au niveau du second site (1 02), associer au se- 
cond noeud (210) par des informations parta- 
gees une seconde definition privee du proces- 
sus (11 8b) contenant une action faisant suite a 
la reception du message par le second site 
(102). 

Procede selon la revendication 3, dans lequel I'eta- 
pe de repartition (504) comprend en outre : 

revoir la definition publique du processus 
(116a) au niveau du second site (102) ; et 
dans le cas d'une approbation de la definition 
publique (1 1 6a) du processus au niveau du se- 
cond site (102), transmettre un signal d'appro- 
bation a partir du second site (102) vers le pre- 
mier site (101), et 

dans le cas d'une desapprobation de la defini- 
tion publique (1 1 6a) du processus au niveau du 
second site (1 02), transmettre un signal de de- 
sapprobation du second site (102) au premier 
site (101). 

Procede selon la revendication 3 ou 4, dans lequel 
retape de repartition (504) comprend en outre : 

dans le cas de la reception au niveau du pre- 
mier site (1 01) d'un signal d'approbation en pro- 
venance du second site (102), 

emettre un message d'engagement vers le 
second site (102) ; 

installer la definition publique (116a) du 
processus et la premiere definition privee 
(118a) du processus au niveau du premier 
site (101) ; et 

dans le cas de la reception au niveau du second 
site (102) du message d'engagement en pro- 
venance du premier site (1 01 ), installer la defi- 
nition publique (116a) du processus et la se- 
, conde definition privee (1 1 8b) du processus au 
niveau du second site (102). 

Procede selon la revendication 3, 4 ou 5, dans le- 
quel I'etape de repartition (504) comprend en outre, 
dans le cas de la reception au niveau du premier 
site (101) d'un signal de desapprobation provenant 
du second site (1 02), I'etape consistant a transmet- 
tre un message d'avortement au second site (1 02). 



55 7, Procede selon Tune quelconque des revendications 
precedentes, comprenant en outre : 

au niveau du premier site (101) transformer la 
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definition publique (116a) du processus en une 
premiere machine d'6tat ; et 
au niveau du second site (102) transformer la 
definition publique (116a) du processus en une 
seconde machine d'etat. 5 

8. Procede selon i'une quelconque des revendications 
pr£c£dentes comprenant en outre : 

enregistrerdans un premier historiqued'execu- 10 
tion de processus I'execution du premier noeud 
(205) de la definition publique (116a) du 
processus ; 

enregistrer dans un second historique d'ex^cu- 
tion de processus ('execution du second noeud '5 
(210) de la definition publique (116a) du 
processus ; 

examiner les premier et second historiques 
d'execution de processus. 



9. Procede pour commander une definition de proces- 
sus commandant un processus entre un premier si- 
te (101) et un second site (102) dans un systeme 
d'informations reparti, ce proced6 comprenant : 



20 



25 



creer (502) au niveau du premier site (1 01 ) une 
definition publique (116a) du processus in- 
cluant un premier noeud (205) associe au pre- 
mier site (101), un second noeud (210) associe 
au second site (102), et un arc (120) interpose 30 
entre le premier noeud et te second noeud ; ' 
repartir (504) la definition publique du proces- 
sus (116a) vers le second site (102) ; 
creer (514) au niveau du premier site (101) une 
premiere definition priv6e (1 1 8a) du processus 35 
assoctee par des informations partag6es au 
premier noeud (205), une action precddant la 
transmission du message a partir du premier 
site (101) etant definie ; et 

creer (514) au niveau du second site (1 02) une 40 
seconde definition prtvee (118b) du processus 
associee par des informations partagdes au se- 
cond noeud (21 0), une action suivant la recep- 
tion du message par le second site (102) etant 
definie. 45 

10. Procede selon la revendication 9, comprenant en 
outre : 

executer le premier noeud (205) de la definition 50 
publique (116a) du processus en executant la 
premiere definition priv6e (118a) du processus 
au niveau du premier site (101) ; et 
a la suite de la reception du message, executer 
le second noeud (210) de la definition publique 55 
(116a) du processus en executant la seconde 
definition privee (1 1 8b) du processus au niveau 
du second site (102). 
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